forked from bitcoin/bitcoin
-
Notifications
You must be signed in to change notification settings - Fork 7
update bitcoin to 0.18.1 #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
pinhopro
wants to merge
10,000
commits into
blinktrade:master
Choose a base branch
from
bitcoin:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2427939 test: forbid copying of DebugLogHelper (Daniel Pfeifer) d6aa266 test: don't throw from the destructor of DebugLogHelper (Vasil Dimov) Pull request description: Throwing an exception from the destructor of a class is a bad practice because the destructor will be called when an object of that type is alive on the stack and another exception is thrown, which will result in "exception during the exception". This would terminate the program without any messages. Instead print the message to the standard error output and call `std::abort()`. --- This change is part of #26812. It is an improvement on its own, so creating a separate PR for it following the discussion at #32604 (comment). Getting it in will reduce the size of #26812. ACKs for top commit: Crypt-iQ: crACK 2427939 l0rinc: Code review reACK 2427939 optout21: crACK 2427939 furszy: utACK 2427939 Tree-SHA512: 918c1e40d2db4ded6213cd78a18490ad10a9f43c0533df64bdf09f0b216715415030e444712981e4407c32ebf552fbb0e3cce718e048df10c2b8937caf015564
… wallets 88b0647 wallet: Always write last hardened cache flag in migrated wallets (Ava Chow) 8a08eef tests: Check that the last hardened cache upgrade occurs (Ava Chow) Pull request description: #32597 set the descriptor cache upgraded flag for newly created wallets, but migrated wallets still did not have the flag set when they are migrated. For consistency, and to avoid an unnecessary upgrade, we should be setting this flag for migrated wallets. The flag would end up being set anyways at the end of migration when the wallet is reloaded as it would perform the automatic upgrade at that time. However, this is unnecessary and we should just set it from the get go. This PR also adds a couple tests to verify that the flag is being set, and that the upgrade is being performed. ACKs for top commit: cedwies: re-ACK 88b0647 rkrux: lgtm ACK 88b0647 pablomartin4btc: ACK 88b0647 Tree-SHA512: 7d0850db0ae38eedd1e6a3bfaa548c6c612182291059fb1a47279a4c4984ee7914ecd02d8c7e427ef67bf9f5e67cbc57a7ae4412fad539e1bf3e05c512a60d69
ef20c2d build, msvc: Update vcpkg manifest baseline (Hennadii Stepanov) Pull request description: This PR updates the vcpkg manifest baseline from the ["2025.03.19 Release"](https://github.com/microsoft/vcpkg/releases/tag/2025.03.19) to the ["2025.08.27 Release"](https://github.com/microsoft/vcpkg/releases/tag/2025.08.27), with the following package changes: - `boost`: 1.87.0 --> 1.88.0 - `qtbase`: 6.8.2#1 -> 6.9.1 - `qttools`: 6.8.2 -> 6.9.1 - `sqlite3`: 3.49.1 --> 3.50.4 The previous update was made in #32213. ACKs for top commit: hodlinator: ACK ef20c2d Tree-SHA512: 3c95fea911e1481b3536958d83dcaa52012abdff350cd08c21b30b3df61a501b2f3272e879882820bb59456066e9270de820bcb47810d3d1b8e8a1267d987d90
…uild 8e434a8 macdeploy: rename macOS output to bitcoin-macos-app.zip (fanquake) 05353d9 macdeploy: combine appname & -zip arguments (fanquake) Pull request description: Output `bitcoin-macos-app.zip`, similar to what we do for Windows: `bitcoin-win64-setup.exe`. ACKs for top commit: hodlinator: re-ACK 8e434a8 willcl-ark: ACK 8e434a8 Tree-SHA512: e762c9866630c4f8c577027ee9492d74a5c7f4b194df73876d702703b9100c356a30986c2f209ba3f3e2d483017f5e61596a2a7cdfae0a684f8dc244420cd108
bf7996c rpc: fix getblock(header) returns target for tip (Sjors Provoost) 4c3c1f4 test: add block 2016 to mock mainnet (Sjors Provoost) Pull request description: A `target` field was added to the `getblock` and `getblockheader` RPC calls in #31583, but it mistakingly always used the tip value. This PR fixes it to return the target for the given block. Because regtest does not have difficulty adjustment, the mainnet test is expanded to cover the fix. A preliminary commit deals with mining block 2016 that's needed for the test. It also: - renames the `create_coinbase` `retarget_period` argument to `halving_period`. Before #31583 this was hardcoded for regtest where these values are the same. - drops unused `fees` argument from `mine` helper - expands the CPU miner instructions for generating the alternative mainnet chain Fixes #33440 ACKs for top commit: sipa: utACK bf7996c luke-jr: crACK bf7996c TheCharlatan: ACK bf7996c ismaelsadeeq: Code review ACK bf7996c Tree-SHA512: 2a2e11efd91f4aaccf9d2ec4dff9fd82c366b8a7e797ce5981dca2e6f08028f69154f4e6a27aef20d78b0e6c3304416789267c2fad42d7aa5072f8537d0c8b0d
…rflow b807dfc miner: fix `addPackageTxs` unsigned integer overflow (ismaelsadeeq) Pull request description: This PR fixes an unsigned integer overflow in the `addPackageTxs` method of the `BlockAssembler`. The overflow is a rare edge case that might occur on master when a miner reserves 2000 WU and wants to create an block to be empty. i.e, by starting with `-blockmaxweight=2000`, `-blockreservedweight=2000`, or just `blockmaxweight=2000`, and then calling the mining interface `createNewBlock` with `blockReservedWeight` set to `2000`. Instead of bailing out after going through transactions equivalent to `MAX_CONSECUTIVE_FAILURES`, the loop never breaks until all mempool transactions are visited. See #33421 (comment) The fix avoids the overflow by using addition instead adding `BLOCK_FULL_ENOUGH_WEIGHT_DELTA` to the block weight and comparing it with `m_options.nBlockMaxWeight`. Another alternative that preserves the same structure is to use `static_cast`. See c9530cf. This fix can be tested by cherry-picking the commits from #33421 without the static cast fix and running: ```bash echo "AQAAAAAAA AAnJycnAAAAAAAAAAAAAAAAAA" | base64 --decode > miner.crash FUZZ=block_template_cache ./build_fuzz/bin/fuzz miner.crash ``` --- This is part of a larger inconsistency in how size/weight is represented in the codebase. It may be worth defining a dedicated type for size/weight. ACKs for top commit: glozow: nice, utACK b807dfc furszy: Code ACK b807dfc Tree-SHA512: c1d2f7e500f9b0624a4c22a146921a1644017065e6c94d0c5027486392321f5de26c61751a24765e025e45b34c535adfd6d0e2ac809dea6846b99f37d13043c9
We can use vswhere.exe directly to create a vs developer prompt and so can remove this third party dependency. Co-authored-by: David Gumberg <[email protected]>
df67bb6 test: Remove convert_to_json_for_cli (Ava Chow) 44a493e cli: Allow arguments to be both strings and json (Ava Chow) Pull request description: There are some RPCs where the argument can be either JSON that needs to be parsed, or a string that we can pass straight through. However, `bitcoin-cli` would always parse those arguments as JSON which makes for some cumbersome argument passing when using those RPCs. Notably, `hash_or_height` in `getblockstats` and `gettxoutsetinfo` do this, and results in a more cumbersome command of `bitcoin-cli getblockstats '"<hash>"'`. Otherwise, using a normal invocation of `bitcoin-cli getblockstats <hash>` results in `error: Error parsing JSON`. This PR marks those particular options as also being a string so that when `bitcoin-cli` fails to parse the argument as JSON, it will assume that the argument is a string and pass it straight through. ACKs for top commit: ryanofsky: Code review ACK df67bb6, just rebased since last review. I do still think it would be good to improve the test (#33230 (comment)) rkrux: Light code review, lgtm ACK df67bb6 mzumsande: Code Review ACK df67bb6 Tree-SHA512: 6c488570fbb24d0cf10508416c56accfc7af5163b7a7187d22d78c812424a9e3ecc95906d3e295fbf6af54bf80903aa448fd879dd6a9944ba8b4d1a33eb29ef2
…C options are used 453b0fa bitcoin: Make wrapper not require -m (Ryan Ofsky) 29e836f test: add tool_bitcoin to test bitcoin wrapper behavior (Ryan Ofsky) 0972f55 init: add exe name to bitcoind, bitcoin-node -version output to be able to distinguish these in tests (Ryan Ofsky) Pull request description: This change makes the `bitcoin` command respect IPC command line options and _bitcoin.conf_ settings, so IPC listening can be enabled by just running `bitcoin node -ipcbind=unix` or `bitcoin node` with `ipcbind=unix` in the configuration file, and there is no longer a need to specify a multiprocess `-m` option like `bitcoin -m node [...]` sipa and theuni in #31802 pointed out that users shouldn't be exposed to multiprocess implementation details just to use IPC features, so current need to specify the `bitcoin -m` option in conjunction with `-ipcbind` could be seen as a design mistake and not just a usage inconvenience. This PR also adds a dedicated functional test for the `bitcoin` wrapper command and to make sure it calls the right binaries and test the new functionality. --- This PR is part of the [process separation project](#28722). ACKs for top commit: Sjors: re-ACK 453b0fa achow101: ACK 453b0fa TheCharlatan: Re-ACK 453b0fa Tree-SHA512: 9e49cb7e183fd220fa7a4e8ac68cef55f3cb2ccec40ad2a9d3e3f31db64c4953db8337f8caf7fce877bc97002ae97568dcf47ee269a06ca1f503f119bfe392c1
316a0c5 rpc: addpeeraddress: throw on invalid IP (John Moffett) Pull request description: Right now we return an opaque `{"success" : false}` in `addpeeraddress` for an empty or invalid IP. This changes it to throw `RPC_CLIENT_INVALID_IP_OR_SUBNET` with the error message `Invalid IP address`. Tests updated to match. ACKs for top commit: sipa: utACK 316a0c5 achow101: ACK 316a0c5 vasild: ACK 316a0c5 pablomartin4btc: tACK 316a0c5 Tree-SHA512: 79a8ce127d0a24b2eb1f31bc3294b895d0c6424032a6b49168259e0e94aff69723d067adf1b4dc3c9b79e597531e5b65e4b8fc5a8e21fba0b81f99168de12b96
QT translations are optional, but the script would error when 'translations_dir' falls back to its default value NULL. This PR fixes it by moving the set-up of QT translations under the check for 'translations_dir' presence.
…plicable 1ff9e92 key: use static context for libsecp256k1 calls where applicable (Sebastian Falbesoner) Pull request description: The dynamically created [signing context](https://github.com/bitcoin/bitcoin/blob/2d6a0c464912c325faf35d4ad28b1990e828b414/src/key.cpp#L19) for libsecp256k1 calls is only needed for functions that involve generator point multiplication with a secret key, i.e. different variants of public key creation and signing. The API docs hint to those by stating "[(not secp256k1_context_static)](https://github.com/bitcoin-core/secp256k1/blob/b4756543028065b3ae6f30e9e6d7f1ecf2bb08c6/include/secp256k1.h#L645)" for the context parameter. In our case that applies to the following calls: - `secp256k1_ec_pubkey_create` - `secp256k1_keypair_create` - `secp256k1_ellswift_create` - `secp256k1_ecdsa_sign` - `secp256k1_ecdsa_sign_recoverable` - `secp256k1_schnorrsig_sign32` - `ec_seckey_export_der` (not a direct secp256k1 function, but calls `secp256k1_ec_pubkey_create` inside) For all the other secp256k1 calls we can simply use the static context. This is done for consistency to other calls that already use `secp256k1_context_static`, and also to reduce dependencies on the global signing context variable. Looked closer at this in the course of reviewing #29675, where some functions used the signing context that didn't need to, avoiding a move to another module (see #29675 (comment)). ACKs for top commit: Eunovo: ACK 1ff9e92 furszy: ACK 1ff9e92 rkrux: crACK 1ff9e92 Tree-SHA512: f091efa56c358057828f3455d4ca9ce40ec0d35f3e38ab147fe3928bb5dbf7ffbc27dbf97b71937828ab95ea4e9be5f96d89a2d29e2aa18df4542aae1b33e258
75e6984 test/refactor: use test deque to avoid quadratic iteration (Lőrinc) Pull request description: Extracted from #33141 (comment). ----- In Python, [list `pop(0)` is linear](https://docs.python.org/3/tutorial/datastructures.html#using-lists-as-queues), so consuming all items in the test results in quadratic iteration. Switching to `collections.deque` with `popleft()` expresses FIFO intent and avoids the O(n^2) path. Behavior is unchanged - for a few hundred items the perf impact is likely negligible. ACKs for top commit: maflcko: lgtm ACK 75e6984 theStack: re-ACK 75e6984 enirox001: reACK 75e6984 w0xlt: reACK 75e6984 Tree-SHA512: 290f6aeeb33d8b12b7acbbfede7ce0bef1c831a7ab9efc9c3a08c049986572e289cdece0844db908cf198395f574575ce4073c268033bf6dbaadc3828c96c1d8
Depending on the host machine, a default `par` value can spawn up to 15 script verification threads for each node. Running the functional test suite with default `par` can exhaust file descriptors or hit other resource limits when many threads are spawned. These threads are mostly idle and the same code paths are executed with a value of `par=2`. Limit this to 2 for functional tests that do not override the default option. Co-authored-by: maflcko <[email protected]>
…criptwitness) ff05beb doc: rpc: fix case typo in `finalizepsbt` help (final_scriptwitness) (Sebastian Falbesoner) Pull request description: The lower-case spelling matches the `decodepsbt` result field: https://github.com/bitcoin/bitcoin/blob/200150beba6601237036bc01ee10f6a0a2246c3d/src/rpc/rawtransaction.cpp#L871 https://github.com/bitcoin/bitcoin/blob/200150beba6601237036bc01ee10f6a0a2246c3d/src/rpc/rawtransaction.cpp#L1253 ACKs for top commit: l0rinc: ACK ff05beb rkrux: Ah crACK ff05beb Tree-SHA512: c0a0e29e95fed3fcee4df4f3fc87b32774d76bebadcda5aa010bc45142727536d6a71e4c0e70564db8bdb734e8647c80953793ac9ecd6c434345e972f8d9b7b0
`CConnman::AlreadyConnectedToAddress()` is the only caller of `CConnman::FindNode(CNetAddr)`, so merge the two in one function. The unit test that checked whether `AlreadyConnectedToAddress()` ignores the port is now unnecessary because now the function takes a `CNetAddr` argument. It has no access to the port.
The removed statements were logged up to two or three times for each loaded wallet. The SQLite version only needs to be logged once. The full wallet path is dropped, since the existing unconditional logging while loading wallets is sufficient (also reduces anonymization efforts in case of sharing logs). Co-authored-by: Martin Zumsande <[email protected]>
Some of the versions used here are > 2 years old. i.e mypy. Use the latest avilable versions, except for LIEF, which is generally changed with Guix.
Using bypass_limits=true is essentially fuzzing part of a reorg only, and results in TRUC invariants unable to be checked. Remove most instances of bypassing limits, leaving one harness able to do so.
Not enforcing TRUC topology on reorg was the intended behavior, but the appropriate bypass argument was not checked. This mistake means we could potentially invalidate a long chain of perfectly incentive-compatible transactions that were made historically, including subsequent non-TRUC transactions, all of which may have been very high feerate. Lastly, it wastes CPU cycles doing topology checks since this behavior cannot actually enforce the topology in general for the reorg setting.
d4f47f9 ci: use latest versions of lint deps (fanquake) Pull request description: Some of the versions used here are > 2 years old. i.e `mypy`. Use the latest avilable versions, except for LIEF, which is generally changed with Guix. Side note. I can't remember the last time one of these tools (mypy, ruff, vulture) actually caught an issue in the lint job. ACKs for top commit: maflcko: lgtm ACK d4f47f9 janb84: lgtm ACK d4f47f9 hebasto: ACK d4f47f9, I have reviewed the code and it looks OK. Tree-SHA512: 8b312535c9fea8e76d58f517ada6d6ea7a119c5e03c8cb84a41b5b6ca80dfaaff65a81478bdc1a5acf734cfb0bc66a8b3ba5400db8973c43ca913b07568abfe4
Ensure the download timestamp is created only after a successful download.
- Also move them to policy/fees/ and update includes - Note: the block_policy_estimator_args.h include in block_policy_estimator_args.cpp was done manually.
51877f2 test: Update BIP324 test vectors (Tim Ruffing) Pull request description: This updates the hardcoded test vectors from BIP324. The test vectors had to be regenerated (in the aux files of the BIP) because there was a bug in the script used for generating them (bitcoin/bips#2016). ACKs for top commit: jonatack: ACK 51877f2 theStack: ACK 51877f2 Tree-SHA512: 59f4075e286067b11fce98667c860f3083b6cca8a2e49da8783ccdce8e32c34fd3e1943191d24dcf5bb68d8a2540726d99f7c29e8b0f104032ccb82423ca8d82
Drop using the git clone & install.
…ts for comparing chain ties) 0465574 test: Fixes send_blocks_and_test docs (Sergi Delgado Segura) 09c95f2 test: Adds block tiebreak over restarts tests (Sergi Delgado Segura) 18524b0 Make nSequenceId init value constants (Sergi Delgado Segura) 8b91883 Set the same best tip on restart if two candidates have the same work (Sergi Delgado Segura) 5370bed test: add functional test for complex reorgs (Pieter Wuille) ab145cb Updates CBlockIndexWorkComparator outdated comment (Sergi Delgado Segura) Pull request description: This PR grabs some interesting bits from #29284 and fixes some edge cases in how block tiebreaks are dealt with. ## Regarding #29284 The main functionality from the PR was dropped given it was not an issue anymore, however, reviewers pointed out some comments were outdated #29284 (comment) (which to my understanding may have led to thinking that there was still an issue) it also added test coverage for the aforementioned case which was already passing on master and is useful to keep. ## New functionality While reviewing the superseded PR, it was noticed that blocks that are loaded from disk may face a similar issue (check #29284 (comment) for more context). The issue comes from how tiebreaks for equal work blocks are handled: if two blocks have the same amount of work, the one that is activatable first wins, that is, the one for which we have all its data (and all of its ancestors'). The variable that keeps track of this, within `CBlockIndex` is `nSequenceId`, which is not persisted over restarts. This means that when a node is restarted, all blocks loaded from disk are defaulted the same `nSequenceId`: 0. Now, when trying to decide what chain is best on loading blocks from disk, the previous tiebreaker rule is not decisive anymore, so the `CBlockIndexWorkComparator` has to default to its last rule: whatever block is loaded first (has a smaller memory address). This means that if multiple same work tip candidates were available before restarting the node, it could be the case that the selected chain tip after restarting does not match the one before. Therefore, the way `nSequenceId` is initialized is changed to: - 0 for blocks that belong to the previously known best chain - 1 to all other blocks loaded from disk ACKs for top commit: sipa: utACK 0465574 TheCharlatan: ACK 0465574 furszy: Tested ACK 0465574. Tree-SHA512: 161da814da03ce10c34d27d79a315460a9c98d019b85ee35bc5daa991ed3b6a2e69a829e421fc70d093a83cf7a2e403763041e594df39ed1991445e54c16532a
58e55b1 test: descriptor: cover invalid multi/multi_a cases (brunoerg) Pull request description: This PR adds test coverage for invalid `multi()` and `multi_a()` cases, see: 1. https://github.com/bitcoin/bitcoin/blob/53eb5593f0a1a8ae5cf0fabea58e2f22193a5c55/src/script/descriptor.cpp#L1819-L1821 2. https://github.com/bitcoin/bitcoin/blob/53eb5593f0a1a8ae5cf0fabea58e2f22193a5c55/src/script/descriptor.cpp#L1835-L1837 3. https://github.com/bitcoin/bitcoin/blob/53eb5593f0a1a8ae5cf0fabea58e2f22193a5c55/src/script/descriptor.cpp#L1838-L1840 We could also exercise to exceed the number of keys - 20 for `multi` and 999 for `multi_a`. ACKs for top commit: maflcko: lgtm ACK 58e55b1 darosior: utACK 58e55b1 glozow: ACK 58e55b1 Tree-SHA512: 0983e9c70e4bef13fa21b2e22e17c2e86eda0950f6271a42b24b91eef22c3277659a862a78bd511c9e14c92859070b3bf2968cfa24de0a1397de1f824946c757
…(if `internal=false`) & disallow label for ranged descriptors 664657e bugfix: disallow label for ranged descriptors & allow external non-ranged descriptors to have label (scgbckbone) Pull request description: Motivation: * ranged descriptors MUST not be able to have label (current impl allows it) * external non-ranged descriptor MUST be able to have label (current impl disallows it, **if** `internal=false` is provided via importdescriptor user data) Repro steps: * create blank wallet and import descriptors * external has `label=test` (not internal) ``` conn = bitcoind.create_wallet(wallet_name=w_name, disable_private_keys=True, blank=True, passphrase=None, avoid_reuse=False, descriptors=True) descriptors = [ { "timestamp": "now", "label": "test", "active": True, "desc": "wpkh([0f056943/84h/1h/0h]tpubDC7jGaaSE66Pn4dgtbAAstde4bCyhSUs4r3P8WhMVvPByvcRrzrwqSvpF9Ghx83Z1LfVugGRrSBko5UEKELCz9HoMv5qKmGq3fqnnbS5E9r/0/*)#erexmnep", "internal": False }, { "desc": "wpkh([0f056943/84h/1h/0h]tpubDC7jGaaSE66Pn4dgtbAAstde4bCyhSUs4r3P8WhMVvPByvcRrzrwqSvpF9Ghx83Z1LfVugGRrSBko5UEKELCz9HoMv5qKmGq3fqnnbS5E9r/1/*)#ghu8xxfe", "active": True, "internal": True, "timestamp": "now" }, ] r = conn.importdescriptors(descriptors) print(r) ``` response: ``` [{'error': {'code': -8, 'message': 'Internal addresses should not have a label'}, 'success': False, 'warnings': ['Range not given, using default keypool range']}, {'success': True, 'warnings': ['Range not given, using default keypool range']}] ``` But in above, ONLY external has a label. If you remove `internal: False` from external descriptor import object - it will import no problem: ``` [{'success': True, 'warnings': ['Range not given, using default keypool range']}, {'success': True, 'warnings': ['Range not given, using default keypool range']}] ``` Even tho it should NOT, as the descriptor is ranged. Current implementation relies on checking user provided data to decide whether desc is ranged. ACKs for top commit: achow101: ACK 664657e rkrux: lgtm crACK 664657e Tree-SHA512: 9e70aea620019c29950ba417d4ae38d65cd94a4f6fcabbc021d67b031de1c44c27d6f6f5cb7e6950a099eb6e58bed9be764d4c6347195daeccb14a5d95c123b2
…32266f1e6059e2 59c4898 guix: remove python-pydantic-core input from LIEF (fanquake) 9f2a692 guix: use Clang & LLVM 19 for macOS build (fanquake) 9570ddb guix: update time-machine to 5cb84f2013c5b1e48a7d0e617032266f1e6059e2 (fanquake) 7b5cc27 guix: patch around riscv issue with newer (2.40+) binutils (fanquake) 91b5cba ci: use Debian Trixie for macOS cross job (fanquake) Pull request description: https://codeberg.org/guix/guix/commit/5cb84f2013c5b1e48a7d0e617032266f1e6059e2 isn't super recent, but it's enough to get access to some newer packages, such as LLVM 19, and avoids having to add any further work arounds for things that we know are fixed later (i.e nsis). Once things upstream have stabilized a bit more (the `core-updates` branch was fairly recently merged), we could look at bumping to something newer. Package updates: (base) glibc 2.35 -> 2.39 binutils 2.38 -> 2.41 diffutils 3.8 -> 3.10 gawk 5.2.1 -> 5.3.0 git-minimal 2.45.2 -> 2.46.0 grep 3.8 -> 3.11 gzip 1.12 -> 1.13 linux-headers 6.1.106 -> 6.1.119 make 4.3 -> 4.4.1 xz 5.2.8 -> 5.4.5 CMake 3.30 becomes available. Clang/LLVM 19 becomes available. Could be used for #32764. ACKs for top commit: hebasto: re-ACK 59c4898. willcl-ark: ACK 59c4898 Tree-SHA512: c44965d5a315e4c862f5e40d8e98c645713405fec72a61055f95b6c68b7d2dcc69a61a084e397a4556d4c1df18f1cfa7a905234643fe4a7df9c58d486e26c097
…ries 02d2b5a ci, iwyu: Treat warnings as errors for specific directories (Hennadii Stepanov) 57a3eac refactor: Fix includes in `index` directory (Hennadii Stepanov) bdb8ead refactor: Fix includes in `crypto` directory (Hennadii Stepanov) 56f2a68 ci: Do not patch `leveldb` to workaround UB in "tidy" CI job (Hennadii Stepanov) Pull request description: This PR is the first step towards treating IWYU warnings as errors. At this stage, it applies only to the `crypto` and `index` directories. ACKs for top commit: maflcko: re-ACK 02d2b5a 💮 ryanofsky: Code review ACK 02d2b5a. Just rebased and update tidy patch comment again since last review willcl-ark: ACK 02d2b5a Tree-SHA512: 1c966e01c47bf3e7d225faa3b819367f757430e2d71e9582fa82d67307aabe3f0d76f69346ee180192e7f5ab194ecc58d2b8ecf178eab26ba3309a6b55bff4b6
944e5ff doc: mention key removal in rpc interface modification (rkrux) Pull request description: A discussion in a previous PR 32618 prompted me to add this note: #32618 (comment) <!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md --> <!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. --> <!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. --> ACKs for top commit: maflcko: lgtm ACK 944e5ff stickies-v: ACK 944e5ff glozow: lgtm ACK 944e5ff Tree-SHA512: f64c086c99e7c73a3ae7d60b2e8e06c8e7a3a49305a66d5c5a96db9b4ebbd01928ab5ccbcbdac26f400d16662f84469c448625e1f55ec2a9a920eff8a05fc379
…stimator.{h,cpp}`
1a7fb5e fees: return current block height in estimateSmartFee (ismaelsadeeq)
ab49480 fees: rename fees_args to block_policy_estimator_args (ismaelsadeeq)
06db08a fees: refactor: rename fees to block_policy_estimator (ismaelsadeeq)
6dfdd7e fees: refactor: rename policy_fee_tests.cpp to feerounder_tests.cpp (ismaelsadeeq)
Pull request description:
This PR is a simple refactoring that does four things:
1. Renames `test/policy_fee_tests.cpp` to `test/feerounder_tests.cpp`.
2. Renames `policy/fees.{h,cpp}` to `policy/fees/block_policy_estimator.{h,cpp}`.
3. Renames `policy/fees_args.cpp` to `policy/fees/block_policy_estimator_args.cpp`.
4. Modifies `estimateSmartFee` to return the block height at which the estimate was made by adding a `best_height` unsigned int value to the `FeeCalculation` struct.
**Motivation**
In preparation for adding a new fee estimator, the `fees` directory is created so we can organize code into `block_policy_estimator` and `mempool` because
a) It would be clunky to add more code directly under `fees`.
b) Having `policy/fees.{h,cpp}` and `policy/mempool.{h,cpp}` would also be undesirable.
Therefore, it makes sense to structure the it as `policy/fees/block_policy_estimator`, `policy/fees/mempool`, etc.
Hence test file were also updated accordingly.
The current block height is also returned because later in #30157 we log the height at which each estimate is made (at the debug log category of fee estimation :) ). This feature is particularly useful for empirical data analysis.
ACKs for top commit:
maflcko:
re-ACK 1a7fb5e 🐤
polespinasa:
re ACK 1a7fb5e
willcl-ark:
ACK 1a7fb5e
janb84:
re ACK 1a7fb5e
Tree-SHA512: fef7ace2a9f262ec0361fb7a46df5108afc46b5c4b059caadf2fd114740aefbb2592389d11646c13d0e28bf0ef2cfcfbab3e659c4d4288b8ebe64725fd1963c0
… example) 57f7c68 test: add functional test for `TestShell` (matching doc example) (Sebastian Falbesoner) 53874f7 doc: test: update TestShell example instructions/options (Sebastian Falbesoner) Pull request description: This PR adds a functional framework test for the `TestShell` class. The primary motivation for this is to avoid that the example instructions for the interactive Python shell in `test-shell.md` get outdated or broken without noticing, a problem we had already several times in the past (see #26520, #27906, #31415). Having a copy is still not perfect, as docs and functional test have to be kept in sync, but I don't expect this to be a problem in practice, assuming the hint in the functional test comment is hopefully noticed if changes are made. Alternatively, the example instructions in `test-shell.md` could be removed with a hint to the functional test (I tend to prefer to keep the docs as-is though, showing the full REPL interaction). The first commit contain two small removal fix-ups in `test-shell.md` regarding the result of the `createwallet` RPC call and the mentioning of the `noshutdown` option that was removed earlier (see #31620). Could be backported to v30. ACKs for top commit: brunoerg: ACK 57f7c68 stratospher: ACK 57f7c68. pinheadmz: ACK 57f7c68 Tree-SHA512: 25c35af46b742bbefce7838708437529bbf613fa3d1f0fba590cacef0acdde82b3a78c7a01459c73eaac26ce3f1041e54092d098f0fc94a8c76ac0b4f4970338
53e4951 Switch to ANSI Windows API in `fsbridge::fopen()` function (Hennadii Stepanov) dbe770d Switch to ANSI Windows API in `Win32ErrorString()` function (Hennadii Stepanov) 06d0be4 Remove no longer necessary `WinCmdLineArgs` class (Hennadii Stepanov) f366408 cmake: Set process code page to UTF-8 on Windows (Hennadii Stepanov) dccbb17 Set minimum supported Windows version to 1903 (May 2019 Update) (Hennadii Stepanov) Pull request description: The main goal is to remove [deprecated](#32361) code (removed in C++26). This PR employs Microsoft's modern [approach](https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page) to handling UTF-8: > Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured for UTF-8, then -A APIs typically operate in UTF-8. This model has the benefit of supporting existing code built with -A APIs without any code changes. TODO: - [x] Handle application manifests properly when building with MSVC. - [x] Bump the minimum supported Windows version to 1903 (May 2019 Update). - [x] Remove all remaining use cases of the deprecated `std:wstring_convert`. - The instance in `subprocess.h` will be addressed in a follow-up PR, as additional tests are likely needed. - The usage in `common/system.cpp` is handled in #32566. Resolves partially #32361. ACKs for top commit: laanwj: re-ACK 53e4951 hodlinator: re-ACK 53e4951 davidgumberg: untested crACK 53e4951 Tree-SHA512: 0dbe9badca8b979ac2b4814fea6e4a7e53c423a1c96cb76ce894253137d3640a87631a5b22b9645e8f0c2a36a107122eb19ed8e92978c17384ffa8b9ab9993b5
53b34c8 ci: use pycapnp 2.2.1 in mac native job (fanquake) 8654328 ci: remove Python version comment from mac config (fanquake) Pull request description: Switch to using v2.2.1 in the mac native job. Remove the git clone & install step. ACKs for top commit: maflcko: lgtm ACK 53b34c8 l0rinc: crACK 53b34c8 hebasto: ACK 53b34c8. Tree-SHA512: e756694c14431aacb3e48104331da88285c7500b4c4599c698f50d721d428ffe61258be075ef526b93c15aa3331f38535ca95249a2ef3ebfc804f61479095d9b
5555bce ci: Document why IN_GETOPT_BIN env var is needed on macOS (MarcoFalke) fabe516 ci: Export the container id in python script (MarcoFalke) fa6aa9f ci: Retry image building once on failure (MarcoFalke) fa4dbe0 ci: Allow overwriting check option in run() helper (MarcoFalke) fa8e4de ci: Use os.environ[key] access when value must be set (MarcoFalke) Pull request description: This should fix #33640. It also contains a few refactor cleanups, which are explained in the corresponding commits. ACKs for top commit: l0rinc: Code review reACK 5555bce kevkevinpal: ACK [5555bce](5555bce) davidgumberg: crACK 5555bce Tree-SHA512: f1ea95b0650e57d6a9f97c575a11ee461832c0715c3d1a24dbfe12ccc5366f295639d4c4827f1d01da460ddf00917ecaa627e7dbd12e405770db6c53c3778a9c
fa0fa0f refactor: Revert "disable self-assign warning for tests" (MarcoFalke) faed118 build: Bump clang minimum supported version to 17 (MarcoFalke) Pull request description: Most supported operating systems ship with clang-17 (or later), so bump the minimum to that and allow new code to drop workarounds for previous clang bugs. (Apart from dropping the small workaround, this bump allows the `ci_native_nowallet_libbitcoinkernel` CI to run on riscv64 without running into an ICE with clang-16.) This patch will only be released in version 31.x, next year (2026). For reference: * https://packages.debian.org/bookworm/clang-19 * https://packages.ubuntu.com/noble/clang (clang-18) * CentOS-like 8/9/10 ship clang-17 (and later) via Stream * FreeBSD 12/13 ship clang-17 (and later) via packages * OpenSuse Tumbleweed ships with https://software.opensuse.org/package/clang (clang21); No idea about OpenSuse Leap On operating systems where the clang version is not shipped by default, the user would have to use GCC, or install clang in a different way. For example: * https://packages.debian.org/bookworm/g++ (g++-12) * https://packages.ubuntu.com/jammy/g++ (g++-11) * https://apt.llvm.org/, or nix, or guix, or compile clang from source, ... *Ubuntu 22.04 LTS does not ship with clang-16 (the previous minimum required), nor with clang-17, so one of the above workarounds is needed there.* macOS 14 is unaffected, and the previous minimum requirement of Xcode15.0 remains, see also https://github.com/bitcoin/bitcoin/blob/919e6d01e93a57d991ed456bc67c43605583ada8/depends/hosts/darwin.mk#L3-L4. (Modulo compiling the fuzz tests, which requires https://github.com/bitcoin/bitcoin/blob/919e6d01e93a57d991ed456bc67c43605583ada8/.github/workflows/ci.yml#L149) ACKs for top commit: janb84: Concept ACK fa0fa0f l0rinc: Code review ACK fa0fa0f hebasto: ACK fa0fa0f. Tree-SHA512: 5973cec39982f80b8b43e493cde012d9d1ab75a0362300b007d155db9f871c6341e7e209e5e63f0c3ca490136b684683de270136d62cb56f6b00b0ac0331dc36
Using std::ranges::copy from the C++ standard library has a few benefits here: * It has the additional benefit of being a bit more type safe and document the byte cast explicitly. * The compiler will likely optimize it to the same asm, but performance doesn't really matter here anyway. * It works around an UB-Sanitizer bug, when the source range is empty. Fixes #33643
…ure (8 bytes DER-encoded) 5fa81e2 test: add valid tx test with minimum-sized ECDSA signature (8 bytes DER-encoded) (Sebastian Falbesoner) Pull request description: Currently in our tests, all ECDSA signatures passing verification have sizes of 69 bytes and above (that's the DER-encoded size, i.e. counted without the sighash flag byte) [1]. This PR adds test coverage for the minimum-sized valid case of 8 bytes, by taking an interesting testnet transaction that I stumbled upon: https://mempool.space/testnet/tx/c6c232a36395fa338da458b86ff1327395a9afc28c5d2daa4273e410089fd433 Note that this is a very obscure construction that only works because the public key used isn't contained in the locking script, but calculated and provided later at spending time (see https://bitcointalk.org/index.php?topic=1729534.msg17309060#msg17309060 for an explainer), to match the message (sighash) and picked signature. So this doesn't represent a use-case that really makes sense in practice, but it can still appear in a block (not in mempool though, due to `SCRIPT_VERIFY_CONST_SCRIPTCODE`), and having test-coverage seems useful. Can be tested with same patch below (tests crash with the condition `>= 9`, but pass with `>= 8`). [1] this can be verified by applying the following patch and running the tests: ```diff diff --git a/src/pubkey.cpp b/src/pubkey.cpp index a4ca9a1..bee0caa603 100644 --- a/src/pubkey.cpp +++ b/src/pubkey.cpp @@ -288,7 +288,9 @@ bool CPubKey::Verify(const uint256 &hash, const std::vector<unsigned char>& vchS /* libsecp256k1's ECDSA verification requires lower-S signatures, which have * not historically been enforced in Bitcoin, so normalize them first. */ secp256k1_ecdsa_signature_normalize(secp256k1_context_static, &sig, &sig); - return secp256k1_ecdsa_verify(secp256k1_context_static, &sig, hash.begin(), &pubkey); + bool ret = secp256k1_ecdsa_verify(secp256k1_context_static, &sig, hash.begin(), &pubkey); + if (ret) assert(vchSig.size() >= 69); + return ret; } ``` ACKs for top commit: ajtowns: ACK 5fa81e2 lgtm fjahr: tACK 5fa81e2 real-or-random: utACK 5fa81e2 interesting case Tree-SHA512: d1f0612fdb71c9238ca0420f574f6f246e60dbd11970b23f21d082c759a89ff98a13b12a1f6266f14f20539ec437b7ab79322082278da32984ddfee2d8893356
66667d6 test: Use same rpc timeout for authproxy and cli (MarcoFalke) Pull request description: It seems odd to use different timeouts (and timeout factors) depending on whether the Python RPC proxy is used, or the bitcoin rpc command line interface. Fix it by using the same timeout. This can be tested by introducing a timeout error and checking it happens with and without `--usecli` after the exact same time. Example timeout error: ```diff diff --git a/test/functional/mining_template_verification.py b/test/functional/mining_template_verification.py index de0833c..e0f93a2b1e 100755 --- a/test/functional/mining_template_verification.py +++ b/test/functional/mining_template_verification.py @@ -173,7 +173,7 @@ class MiningTemplateVerificationTest(BitcoinTestFramework): self.log.info("Submitting this block should succeed") assert_equal(node.submitblock(block.serialize().hex()), None) - node.waitforblockheight(2) + node.waitforblockheight(200000) def transaction_test(self, node, block_0_height, tx): self.log.info("make block template with a transaction") ``` Example cmd: `./bld-cmake/test/functional/mining_template_verification.py --timeout-factor=0.1 --usecli`. ACKs for top commit: brunoerg: ACK 66667d6 stickies-v: tACK 66667d6 Tree-SHA512: c8c21d8b9fb60ab192e3bbd45b317b96a40e10bf03704148613ac3cbdaae4abc2c03c4afbd504309ea0958201267c0d2a4bc5b40aa020917175c47e080ffe292
…nd ubsan warn fa4b52b fuzz: refactor memcpy to std::ranges::copy to work around ubsan warn (MarcoFalke) Pull request description: Using std::ranges::copy from the C++ standard library has a few benefits here: * It has the additional benefit of being a bit more type safe and document the byte cast explicitly. * The compiler will likely optimize it to the same asm, but performance doesn't really matter here anyway. * It has defined semantics for empty source ranges. Fixes #33643 ACKs for top commit: marcofleon: tACK fa4b52b dergoegge: utACK fa4b52b Tree-SHA512: 04fcf096e3cfc526e996c9313ec6e0a4d12c382fa19cb846b51564d33de2f0ef78a588fc6a936da0c76ca8bc9d9db4a824c36d99413db4f538a98239864d48f0
facf8b7 ci: Add missing python3-dev package for riscv64 (MarcoFalke) Pull request description: This is required to compile the pip wheels on native riscv64. ACKs for top commit: fanquake: ACK facf8b7 Tree-SHA512: 7305deda4f2a7c2be5a82f4fcbc110f20a154374d98442e56d50175edda7f37a68b8e4cc1d84fc1fbc69ec1cc28559bbe795cc553fae8bd2e5effc36b0e534a2
`format!` strings may contain variables within the string representation. This is a lint as of a recent `rustc` nightly version.
78d4d36 test: Format strings in `*.rs` (rustaceanrob) Pull request description: `format!` strings may contain variables within the string representation. This is a lint as of a recent `rustc` nightly version. ACKs for top commit: maflcko: lgtm ACK 78d4d36 TheCharlatan: ACK 78d4d36 rkrux: crACK 78d4d36 Tree-SHA512: d6da94682dfa35964be4d7bba323847bae040dcec921e3d4ee2f25400751fa3af40fafe27805c2d6587d00a8ff54cc6af22ca46bf8911f13a200e73e77daa019
51093d6 test: resolve symlinks in which result for capnp (David Gumberg) Pull request description: On Fedora, `/bin/` and `/usr/bin` are symlinked, and on one of my boxes (although I could not reproduce this behavior in a docker container), `/bin` comes before `/usr/bin` in `$PATH`, so `which capnp` reports `/bin/capnp`, and `capnp_dir` is set to `/include`, and the test fails: ```console $ ./build/test/functional/interface_ipc.py 2025-10-30T20:43:43.753812Z TestFramework (INFO): PRNG seed is: 8370468257027235753 2025-10-30T20:43:43.754163Z TestFramework (INFO): Initializing test directory /tmp/bitcoin_func_test_b9kjzj2a terminate called after throwing an instance of 'kj::ExceptionImpl' what(): mp/proxy.capnp:6: failed: Import failed: /capnp/c++.capnp Aborted (core dumped) ``` This changes the functional test to resolve any symlinks in the `capnp` binary path reported by `which`. ACKs for top commit: TheCharlatan: utACK 51093d6 ryanofsky: Code review ACK 51093d6 Tree-SHA512: 17a3e16c3ef50d19e65c18bd12636f287b41e54fc14629e2eb6efb8f9532af7e0e0d404e4e234eeba92473b7ae18d97144a953d28523670308e78e4c4fbb7137
…32 MiB b6f8c48 coins: increase default `dbbatchsize` to 32 MiB (Lőrinc) 8bbb7b8 refactor: Extract default batch size into kernel (Lőrinc) Pull request description: This change is part of [[IBD] - Tracking PR for speeding up Initial Block Download](#32043) ### Summary When the in-memory UTXO set is flushed to LevelDB (after IBD or AssumeUTXO load), it does so in batches to manage memory usage during the flush. A hidden `-dbbatchsize` config option exists to modify this value. This PR only changes the default from `16` MiB to `32` MiB. Using a larger default reduces the overhead of many small writes and improves I/O efficiency (especially on HDDs). It may also help LevelDB optimize writes more effectively (e.g., via internal ordering). The change is meant to speed up a critical part of IBD: dumping the accumulated work to disk. ### Context The UTXO set has grown significantly since [2017](https://github.com/bitcoin/bitcoin/pull/10148/files#diff-d102b6032635ce90158c1e6e614f03b50e4449aa46ce23370da5387a658342fdR26-R27), when the original fixed 16 MiB batch size was chosen. With the current multi-gigabyte UTXO set and the common practice of using larger `-dbcache` values, the fixed 16 MiB batch size leads to several inefficiencies: * Flushing the entire UTXO set often requires thousands of separate 16 MiB write operations. * Particularly on HDDs, the cumulative disk seek time and per-operation overhead from numerous small writes significantly slow down the flushing process. * Each `WriteBatch` call incurs internal LevelDB overhead (e.g., MemTable handling, compaction triggering logic). More frequent, smaller batches amplify this cumulative overhead. Flush times of 20-30 minutes are not uncommon, even on capable hardware. ### Considerations As [noted by sipa](#31645 (comment)), flushing involves a temporary memory usage increase as the batch is prepared. A larger batch size naturally leads to a larger peak during this phase. Crashing due to OOM during a flush is highly undesirable, but now that [#30611](#30611) is merged, the most we'd lose is the first hour of IBD. Increasing the LevelDB write batch size from 16 to 32 MiB raised the measured peaks by ~70 MiB in my tests during UTXO dump. The option remains hidden, and users can always override it. The increased peak memory usage (detailed below) is primarily attributed to LevelDB's `leveldb::Arena` (backing MemTables) and the temporary storage of serialized batch data (e.g., `std::string` in `CDBBatch::WriteImpl`). Performance gains are most pronounced on systems with slower I/O (HDDs), but some SSDs also show measurable improvements. ### Measurements: AssumeUTXO proxy, multiple runs with error bars (flushing time is faster that the measured loading + flushing): * Raspberry Pi, dbcache=500: ~30% faster with 32 MiB vs 16 MiB, peak +~75 MiB and still < 1 GiB. * i7 + HDD: results vary by dbcache, but 32 MiB usually beats 16 MiB and tracks close to 64 MiB without the larger peak. * i9 + fast NVMe: roughly flat across 16/32/64 MiB. The goal here is to avoid regressions, which holds. ### Reproducer: ```bash # Set up a clean demo environment rm -rfd demo && mkdir -p demo # Build Bitcoin Core cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j$(nproc) # Start bitcoind with minimal settings without mempool and internet connection build/bin/bitcoind -datadir=demo -stopatheight=1 build/bin/bitcoind -datadir=demo -blocksonly=1 -connect=0 -dbcache=3000 -daemon # Load the AssumeUTXO snapshot, making sure the path is correct # Expected output includes `"coins_loaded": 184821030` build/bin/bitcoin-cli -datadir=demo -rpcclienttimeout=0 loadtxoutset ~/utxo-880000.dat # Stop the daemon and verify snapshot flushes in the logs build/bin/bitcoin-cli -datadir=demo stop grep "FlushSnapshotToDisk: completed" demo/debug.log ``` --- This PR originally proposed 64 MiB, then a dynamic size, but both were dropped: 64 MiB increased peaks more than desired on low-RAM systems, and the dynamic variant underperformed across mixed hardware. 32 MiB is a simpler default that captures most of the gains with a modest peak increase. For more details see: #31645 (comment) --- While the PR isn't about IBD in general, rather about a critical section of it, I have measured a reindex-chainstate until 900k blocks, showing a 1% overall speedup: <details> <summary>Details</summary> ```python COMMITS="e6bfd95d5012fa1d91f83bf4122cb292afd6277f af653f3"; \ STOP=900000; DBCACHE=10000; \ CC=gcc; CXX=g++; \ BASE_DIR="/mnt/my_storage"; DATA_DIR="$BASE_DIR/BitcoinData"; LOG_DIR="$BASE_DIR/logs"; \ (echo ""; for c in $COMMITS; do git fetch -q origin $c && git log -1 --pretty='%h %s' $c || exit 1; done; echo "") && \ hyperfine \ --sort command \ --runs 1 \ --export-json "$BASE_DIR/rdx-$(sed -E 's/(\w{8})\w+ ?/\1-/g;s/-$//'<<<"$COMMITS")-$STOP-$DBCACHE-$CC.json" \ --parameter-list COMMIT ${COMMITS// /,} \ --prepare "killall bitcoind 2>/dev/null; rm -f $DATA_DIR/debug.log; git checkout {COMMIT}; git clean -fxd; git reset --hard && \ cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release && ninja -C build bitcoind && \ ./build/bin/bitcoind -datadir=$DATA_DIR -stopatheight=$STOP -dbcache=1000 -printtoconsole=0; sleep 10" \ --cleanup "cp $DATA_DIR/debug.log $LOG_DIR/debug-{COMMIT}-$(date +%s).log" \ "COMPILER=$CC ./build/bin/bitcoind -datadir=$DATA_DIR -stopatheight=$STOP -dbcache=$DBCACHE -reindex-chainstate -blocksonly -connect=0 -printtoconsole=0" e6bfd95 Merge bitcoin-core/gui#881: Move `FreespaceChecker` class into its own module af653f3 coins: derive `batch_write_bytes` from `-dbcache` when unspecified Benchmark 1: COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=900000 -dbcache=10000 -reindex-chainstate -blocksonly -connect=0 -printtoconsole=0 (COMMIT = e6bfd95) Time (abs ≡): 25016.346 s [User: 30333.911 s, System: 826.463 s] Benchmark 2: COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=900000 -dbcache=10000 -reindex-chainstate -blocksonly -connect=0 -printtoconsole=0 (COMMIT = af653f3) Time (abs ≡): 24801.283 s [User: 30328.665 s, System: 834.110 s] Relative speed comparison 1.01 COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=900000 -dbcache=10000 -reindex-chainstate -blocksonly -connect=0 -printtoconsole=0 (COMMIT = e6bfd95) 1.00 COMPILER=gcc ./build/bin/bitcoind -datadir=/mnt/my_storage/BitcoinData -stopatheight=900000 -dbcache=10000 -reindex-chainstate -blocksonly -connect=0 -printtoconsole=0 (COMMIT = af653f3) ``` </details> ACKs for top commit: laanwj: Concept and code review ACK b6f8c48 TheCharlatan: ACK b6f8c48 andrewtoth: ACK b6f8c48 Tree-SHA512: a72008feca866e658f0cb4ebabbeee740f9fb13680e517b9d95eaa136e627a9dd5ee328456a2bf040401f4a1977ffa7446ad13f66b286b3419ff0c35095a3521
…comment 1a1f46c refactor/doc: Add blockman param to `GetTransaction` doc comment and reorder out param (Musa Haruna) Pull request description: Follow-up to [#27125](#27125 (comment)) This PR addresses a minor documentation and style nit mentioned during review: - Adds the missing `@param[in] blockman` line to the `GetTransaction()` doc comment. - Moves the output parameter `hashBlock` to the end of both the function declaration and definition, as suggested in the comment. ACKs for top commit: l0rinc: ACK 1a1f46c maflcko: re-lgtm-ut-cr-rfm-ACK 1a1f46c kevkevinpal: reACK [1a1f46c](1a1f46c) Tree-SHA512: 5807a1ae6c383e691e948648dcb1e029620eaff3dcdff73d88c6dc268a7af5559a30c491b72f038b3f7e812e1845f4f063b49bd3671edfac1bb3a170c84be4f5
07a9264 node: change a tx-relay on/off flag to enum (Vasil Dimov) Pull request description: Previously the `bool relay` argument to `BroadcastTransaction()` designated: ``` relay=true: add to the mempool and broadcast to all peers relay=false: add to the mempool ``` Change this to an `enum`, so it is more readable and easier to extend with a 3rd option. Consider these example call sites: ```cpp Paint(true); // Or Paint(/*is_red=*/true); ``` vs ```cpp Paint(RED); ``` The idea for putting `TxBroadcastMethod` into `node/types.h` by Ryan. --- This is part of [#29415 Broadcast own transactions only via short-lived Tor or I2P connections](#29415). Putting it in its own PR to reduce the size of #29415 and because it does not logically depend on the other commits from there. ACKs for top commit: optout21: ACK 07a9264 kevkevinpal: ACK [07a9264](07a9264) laanwj: Concept and code review ACK 07a9264. Agree with the general reasoning and the change in #29415 is a valid motivation to change this interface. glozow: utACK 07a9264 Tree-SHA512: ec8f6fa56a6d2422a0fbd5941ff2792685e8d8e7b9dd50bba9f3e21ed9b4a4a26c89b0d7e4895d48f30b7a635f2eddd894af26b5266410952cbdaf5c40b42966
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.